package own.stu.jobgib.playown.dp.bridge;

import lombok.Data;
import own.stu.jobgib.playown.dp.bridge.model.NotificationEmergencyLevel;

import java.util.List;

@Data
public class Notification {

    private List<String> emailAddresses;

    private List<String> telephones;

    private List<String> wechatIds;

    /**
     *
     * Notification 类的代码实现有一个最明显的问题，那就是有很多 if-else 分支逻辑。实际
     * 上，如果每个分支中的代码都不复杂，后期也没有无限膨胀的可能（增加更多 if-else 分支
     * 判断），那这样的设计问题并不大，没必要非得一定要摒弃 if-else 分支逻辑。
     *
     * 不过，Notification 的代码显然不符合这个条件。因为每个 if-else 分支中的代码逻辑都比
     * 较复杂，发送通知的所有逻辑都扎堆在 Notification 类中。我们知道，类的代码越多，就
     * 越难读懂，越难修改，维护的成本也就越高。很多设计模式都是试图将庞大的类拆分成更细
     * 小的类，然后再通过某种更合理的结构组装在一起。
     *
     * 针对 Notification 的代码，我们将不同渠道的发送逻辑剥离出来，形成独立的消息发送类
     * （MsgSender 相关类）。其中，Notification 类相当于抽象，MsgSender 类相当于实
     * 现，两者可以独立开发，通过组合关系（也就是桥梁）任意组合在一起。所谓任意组合的意
     * 思就是，不同紧急程度的消息和发送渠道之间的对应关系，不是在代码中固定写死的，我们
     * 可以动态地去指定（比如，通过读取配置来获取对应关系）。
     *
     */
    public void notify(NotificationEmergencyLevel level, String message) {
        if (level.equals(NotificationEmergencyLevel.SEVERE)) {
            //...自动语音电话
        } else if (level.equals(NotificationEmergencyLevel.URGENCY)) {
            //...发微信
        } else if (level.equals(NotificationEmergencyLevel.NORMAL)) {
            //...发邮件
        } else if (level.equals(NotificationEmergencyLevel.TRIVIAL)) {
            //...发邮件
        }
    }
}